Hello inhabitants of a remote and unexplored planet full of life, richness and natural resources. The group of entities we are bringing to high resolution currently is the combinators. The main problem with them is the amount of shifting values needed, so we used a specific workflow which I will try to show and explain today. Some of the parts have already been described in FFF 146, so I will only mention what is necessary for this article. Please fasten your belt as this will be a ride full of automation.

Hello!

0.16 to be declared stable Rseding thinks that we have the least amount of bugs in the game we ever had. Mostly because of the automated reporting system and partly because of my pushing of everyone to fix everything before starting other tasks. The 0.16.35 (to be released soon) will be declared stable on Monday, if no critical problems are discovered. This naturally leads us to:

Hello, it seems the summer heat has finally subsided, and we have not had to run our AC units the whole week. We mentioned earlier we have had Dominik in for a testing week, and we are happy to say that he is quite qualified for a position here, so will be remaining with us. Tom has also joined us, moving here from the Republic of Ireland, and has been getting settled in working through a lot of the small unassigned tasks. It also seems most of us are back from our vacations, so the pace is picking up again. Most of the work this week has been on the unentertaining spectrum, with a lot of internal reworking and refactoring going on. A lot commits related to fixing our compilation after the move to C++17. Many of the GUI and input action functions were broken (such as rebinding keys, switch map editor tabs, setting combinator filters), so its been a team effort to fix these as they are found. Hopefully not many will slip through the cracks and into release.

AMD Ryzen crashes (Klonan) The long fight with the elusive Ryzen bug (more and more) seems to finally have some resolution. A few weeks ago I sent an email to AMD, filling them in on the details of the crash, and asked them if they could help us solve this. Very quickly I was put in touch with a member of their CPU engineering team, and they got to work with their investigation. After a few days, and after providing them all the information we have (log files, source code, crash dumps etc.), the cause of the issue was identified. Some other developers in the industry also had this problem and worked with AMD to fix it, so it's unlikely that the CPU bug was fixed only because of us, but we are honoured to have contributed to this. Unfortunately we do not have any technical or deep insight into where exactly the problem lay, or what the fix was, as it was somewhere between the motherboard BIOS and the Ryzen chipset drivers. So if you are running Factorio on a Ryzen system, we advise you to update your BIOS using the files and procedures found on your motherboard manufacturer's website, and update your chipset drivers to the latest version.

Factorio Nomenclature Abregado Today I want to discuss some common problems that we see in video games. Inconsistent Terminology When I asked out loud "So what is an Intermediate Product anyway?", I got a similar reaction as when someone mentions The Berlin Interpretation at a rougelike convention. So what is an Intermediate Product? Well it is a product that is used only as an ingredient for something else. No, that's not right because Science Packs are not used in any recipe. So what then, Intermediate products are just things that you can use Productivity Modules on? Perhaps they are simply items that can be found in the Intermediate Crafting menu. Then are they not Intermediate Recipes? To give another example, answer these questions: Name the action a player performs when they add an entity to the world? Name the action a player performs when they remove an entity from the world? Name the action a player performs when they add a ghost entity to the world? Name the action a robot performs when they add an entity to the world? Name the action a robot performs when they remove an entity from the world? Here are a few situations where the game displays your possible answers: A player builds. A player mines entities. Robots repair and build entities, but wait… the player places buildings and builds ghosts? But here Robots are constructing machines. Here the robots are deconstructing items! This leads into a discussion about what is an item and what are entities, and that discussion leads us into the next point... Internal nomenclature leaking out During game development it is very common to use internal names to refer to mechanics, items, or characters. It does not feel like such a big deal, and many early access games simply ignore the problem completely. I'm not going to point any fingers, but if you look you will find some examples. Oh wait, here is some from your favourite early access game! Internally, things that exist on a surface in the game are called entities. All these items are capsules internally, but only 5 of them are actually labelled as capsules. Really, these should be categorised by how players use them, and indeed there is an attempt to do so. Remotes are items used to trigger an effect, Grenades are things you throw... but why is the Poison Capsule not called a gas grenade? There are more inconsistencies but to keep this article reasonably not-short, I will let you find the others yourself (and to save something for a future FFF about Tooltips). Why change? You might be thinking that this is not a big problem. Some others might be thinking that the problem is too pervasive to bother changing. There are a few reasons why it is important, the first, and most important of which is our quality mindset; everyone on the team here wants the game to be as great as possible. Next we should see this increase the quality of the translations. A translation is only as good as its source, and having a consistent usage of words can go a long way to helping the translators do better work. The effect of this can be increased by providing a dictionary of important words to the translators so they can be sure to always use the same term in all places. Since we are also working on a guided experience (Campaign), this would also help us give much clearer instructions to the player. An example of confusion here would be if one quest said "Place a chest" and another said "Place the item in the chest". The player needs to read the entire quest caption (probably twice), and can never build up a mental map of our language. This leads to the player spending more mental energy (cognitive load) while playing the game. Changing this to "Build a chest" and being consistent, allows the player to create mental shortcuts, meaning the quest tasks require less effort to understand. Finally, consistency in terminology will help new players, and I don't just mean sub-1 hour playtime players. Factorio is a 'Big Game' and players are encountering new items, entities, concepts, and text for a long time. How many hours did you play before you discovered this helpful trick, or this one? How to change? We could make the vocabulary consistent with what the current player base uses. This option sounds pretty good until I started asking people questions similar to those I asked you at the beginning of the article. Here are another two as a refresher: Where do biters come from? I come in 7 colors, what am I? The only wrong answer is if you said there was only a single right answer. Prepare your rotten tomatoes, Ben is about to say something unpopular. The influx of players that are to be expected from 1.0 give us an interesting option. We could theoretically change the vocabulary of the game to be more consistent, reasonable, and generally more helpful to players. Then, as new players join the community, this new language will slowly replace the old. This would help ease communication between all players; veterans and new addicts alike. Consistency will also help polish the experience to the level that players expect from the game. Who should change it? Before Rseding jumps in with some awesome news, I would ask you to have your say in this Google form. It will be fun to see what you come up with, and I will publish the results in a few weeks.

The Character GUI Twinsen It was 11 months ago when we first mentioned the new Character GUI, in FFF-289. After all that time, it's finally getting ready. Since you can expect to see it released sometime in the next 1 or 2 weeks, we would like to present a quick recap of the features and changes, and some real in-game screenshots. ​ The Character window is now split into 3 tabs. Logisitcs and auto-trash were moved from the central frame into a tab and a new tab called Character was added. Using inventory/stack transfers in the player inventory will transfer the items either to weapons and armor slots or to trash slots depending on the selected tab, regardless of item type. Logistics and auto trash are now merged into 1 panel. Using a double slider you can set an interval. If you have less than the first value, robots will bring more, if you have more than the second value, extra items will be auto-trashed and taken away by the robots. The double pop-up and extra confirm might seem strange, but it's made this way to solve the problem of robots bringing you items before you finished setting up your request. With the merging of requests and auto-trash, we also made it so you can now set an unlimited number of requests, regardless of research. Furthermore, everything is unlocked in one research: unlimited logistic requests, auto trash, and 30 trash slots are all unlocked by the "Logistic robotics" research that is at blue science. Searching now not only searches the recipe GUI, but also the inventory and logistic requests. By popular demand, we also added a switch to quickly turn personal logics on or off. Turning off personal logistics will stop logistic robots from bringing requested items. It will also stop items from automatically being moved to the trash slots. Logistic robots will continue to empty the trash slots. Since the recipe GUI has a new style, we also updated the look of the filter, item, circuit signal, and upgrade selection GUI styles. Some of the other GUIs in the game will have some visual issues due to the mix of old and new styles. My next step will be to fix these issues as soon as the Character GUI is released. Looking back, this GUI took 13 months and 3 programmers (working alternatively) to implement. This is excluding mockups and UX design. It's a long story, but one thing that's obvious is that the GUI scope has grown far beyond what our codebase is capable of. For this reason, we won't be focusing obsessing that much on the GUI in the future. We will finalize the transition of styles, fix obvious issues and low hanging fruits, and try to get everything at a consistent level of quality for 1.0. This new Character GUI and changes will likely affect some mods, especially those relying on logistic technologies, logistic slot related APIs, old style definitions, etc. Thankfully a lot of mods will be unaffected, so we hope it won't be too much disruption. Still, we wanted to give some forewarning.

Hello, The year is wrapping up, and we have been hard at work finishing off some topics before we take our Christmas break. As you can imagine, releasing any new version of the game without a few weeks to do bugfixing wouldn't be wise, so you can rest easy this holiday period without the worry of a surprise 0.18 release.

Hello, we are going to focus on the general improvements of the way circuit network is used in the game. I wasn't using it often, because all the problems combined made it too big of a hassle most of the time, which was an indication of problems. So we improved each part of the process of using it a little, from UI, to feedback of what is going on, to stronger/more accessible combinator functionality. I can say that it worked, at least for me. Once these changes were available, I used the circuit network way more in my latest playthrough, and it felt good, so lets hope it won't be just me :)

Hello, This past weekend we beat our previous record of most simultaneous players with a peak player count on Steam of 22,457 players, and no doubt another couple thousand playing the non-Steam version.